[レポート] CON301: Mastering Kubernetes on AWS #reinvent

AWS re:Invent 2018

#Docker

#Amazon EKS

#AWS

Guri / Hajime Oguri

2018.11.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

大栗です。

現在re:Inventに来ています。こちらでKubernetesのセッションに参加したのでレポートします。

Mastering Kubernetes on AWS

本記事はAWS re:Invent 2018のセッション「CON301-R -- [REPEAT] Mastering Kubernetes on AWS」のレポートです。

Kubernetes offers a powerful abstraction layer for managing containerized infrastructure. Amazon Elastic Container Service for Kubernetes (Amazon EKS) makes it easy to run Kubernetes on AWS without having to manage master nodes or the etcd operator. In this session, we cover what you need to know to get your application up and running with Kubernetes on AWS. We show how Amazon EKS makes deploying Kubernetes on AWS simple and scalable, including networking, security, monitoring, and logging.

スピーカーはAWSのシニアビジネスデベロップメントマネージャーであるYaniv Donenfeld氏とSnapchatのSenior Director of EngineeringｓであるKarl D'Adamo氏です。

レポート（AWSパート）

開発でコンテナを動かすのは簡単です。このコマンドだけでできます。

# vi Dockerfile
# docker build -t mykillerapp:0.0.1 .
# docker run -it mykillerapp:0.0.1 .

しかし本番環境のデータプレーンは大量にあったり、コントロールプレーンを高可用に維持しなければなりません。

そう、すごく大変です。

Kubernetesのワークロードの51%はAWSで動いています。

そこでAmazon EKSです。

クロスアカウントでEKSを起動して、コントロールプレーンとワーカーノードを別アカウントに展開することもできます。

Networking: Pod to pod

Kubernetesのネットワークには3個のルールがあります。

すべてのPodはNAT無しで直接通信する
すべてのノードがすべてのPodとNAT無しで通信する（逆も同様）
Podがそれ自体で見ているIPは、他が見ているのと同じIP

AWS VPC CNI plugin

プライマリのCIDRレンジはRFC 1918のアドレスの範囲になるので、"10/8", "172.16/12", "192.168/16"となります。

EKSではPod、マスタからワーカーへの通信（exec、ログ、プロキシなど）、インターナルKubernetesサービスネットワーク(VPCのレンジに10.100/16か172.20/16を選択)で使用する。
セットアップは、EKSクラスタを作成して、サブネットのリスト（少なくとも2AZ）を設定して、タグの設定。

セカンダリのCIDRレンジ（New!）はRFC 1918以外のアドレス（100.64.0.0/10, 198.19.0.0/16）が利用できる

Amazon EKSではPodのみで使用できる。（CNI 1.2.1以上）
Amazon EKSのカスタムネットワークの設定、有効化、ENIConfig CRDの作成、ノードのアノテーション設定

AWS VPC CNI pluginの設定可能性

カスタムネットワーク設定
SNAT / 外部SNAT
設定可能なウォームプール

Networking: Pod to service

サービスタイプがClusterIPの場合は、

クラスタのインターナルIP上にサービスを公開する
クラスタ内からのみアクセス可能
kube-proxy経由でアクセス可能
バッキングサービス、ラップトップからの接続、内部ダッシュボードの表示に役立つ

サービスタイプがNodePortの場合は、

各ノードの静的ポートにサービスを公開する
クラスタIPへのルーティング、これは自動で作成される
クラスタの内部から :
1ポートに1サービス
ポートは30000-32767

サービスタイプがLoadBalancerの場合は、

クラウドプロバイダーのロードバランサを使って外部にサービスを公開する
NodePortとClusterIPサービス（LBにルーティングされる）が自動で作成される。
ロードバランサ付きの各サービスは自分のIPアドレスを得る
L4（TPC）かL7（HTTP）サービスを公開する

サービスロードバランサー: NLB

NLBはクライアントのIPアドレスの転送をサポートしている

. spec.exteralTrafficPolicy = Local の場合はクライアントIPがポッドに渡される
一致するポッドのないノードは指定されたNLBのヘルスチェック .spec.healthCheckNodePort で削除される
DaemonSetかPodアンチアンフィニティを使用してトラフィックを分離する

サービスタイプがExternalNameの場合は、

サービスをCNAME（externalNameフィールド）にをマッピングする
プロキシを使用しない
他のサービスを同様にmy-serviceワーカーにアクセスする
DNSレベルのリダイレクトが起こる（プロキシやフォワードでなく）

Kubernetesの入力オブジェクト

サービス内のクラスタへのルートをHTTP/HTTPSで公開する
様々な実装: ALB、Nginx、F5、HAProxyなど
デフォルトのサービスタイプはClusterIP

Logging: workers

EFKでロギングを実装

EKSのワーカーノードに対してdaemonsetでfluentdを起動、CloudWatch Logsを経由したり直接でElasticsearch Serviceにサブスクライブして、kibanaで可視化する

レポート（Snapchatパート）

Snapchatでは、インフラストラクチャのゴールとして、柔軟性、セキュリティ、可用性/性能、コスト低減、運用作業の最小化の5つを上げています。

2016年のSnapの技術状況は、少数の大きなモノリシックアプリケーションでした。プロジェクトは柔軟性がなく、インプラストラクチャは長いポールから始まりました。

2016年での悪い点は、組織の境界で別の方法になっていました。中央のチームのシングルスレッドの仕事。新しいプロジェクトチームは成約によって楽しくありませんでした。

古いアーキテクチャでは地域化が不可能でした。性能問題がたくさんあり、普通にやることがスタックして、チームは新しい地域でサービスを展開できませんでした。

サービス指向アーキテクチャ

我々は他の組織のマイクロサービスの価値を見てきた。しかしSOAがベストなアプローチなのだろうか？

ポータビリティ

我々の戦略は常にベスト・オブ・ブリードだったのでコンテナは自明でした。

オーケストレーションの半分は戦いです。ベンダーに任せましょう。

大きなサービスの集まりを管理するという問題の解決して、自分たちで動かすのか？Amazon EKSで高いポータビリティ、マネージドコントロールプレーンでオペレーションの削減。

SnapでのAmazon EKS

今後の見通し
- 本番は6サービスを本番環境に投入している。ho
- 2019年の終わりには30-50のサービスを本番投入予定。
- 最終的には数百サービスをEKSに、マルチリージョンの異なったポリシーの冗長咲かれたサービスを乗せる。
本番サービスのEKSの規模
- 7,500コアのCPU
- 毎秒250,000トランザクション
- セキュアなサービスメッシュの高密度なPod/ノード比率
- 2019年にはグローバルな地域化